arXiv:1505.05373vl [cs.AI] 20 May 2015 


Towards a Simulation-Based Programming Paradigm for 

AI applications 1 

Jorg Piihrer 2 


Abstract. We present initial ideas for a programming paradigm 
based on simulation that is targeted towards applications of artificial 
intelligence (AI). The approach aims at integrating techniques from 
different areas of AI and is based on the idea that simulated entities 
may freely exchange data and behavioural patterns. We define basic 
notions of a simulation-based programming paradigm and show how 
it can be used for implementing AI applications. 

1 Introduction 

Artificial intelligence (AI) is a wide field of research in which many 
different outstanding techniques have been developed and refined 
over the last decades 02) . Naturally, the question arises how to cou¬ 
ple or integrate different subsets of these accomplishments. Besides 
many approaches to couple specific individual methods, a need for 
a wider integration of different AI techniques has been identified in 
the area of artificial general intelligence |[T6 i IQ I - Here, the goal is 
to build strong AI systems, i.e., reach human level intelligence. Ar¬ 
guably, integration of existing techniques is also desirable for less 
ambitious AI applications (that we aim for), consider for instance the 
realisation of intelligent opponents in computer games as a motivat¬ 
ing example. As a side remark, note that current solutions for game 
AI rarely make use of techniques from reseach in AI but are often 
ad-hoc, based on hardcoded strategies, and incapable of learning. 

Simulation has been used in different fields of AI (such as agent- 
based systems 1121 1181 or evolutionary computation 0j) for achiev¬ 
ing intelligent behaviour. The rationale is that many aspects of in¬ 
telligent behaviour are complex and not well understood but can be 
observed to emerge when the environment in which they occur is 
simulated adequately. In this work, we propose to use a simulation 
environment for realising AI applications that offers an easy way to 
integrate existing methods from different areas of AI such as com¬ 
putational intelligence, symbolic AI, or statistical methods. In par¬ 
ticular, we present the basic cornerstones of a simulation-based pro¬ 
gramming paradigm (SBP) and demonstrate how it can be used to 
model different use cases for intelligent systems. The basic idea of 
SBP is to simulate an environment of interacting entities driven by 
concurrent processes. Entities are not grouped in types or classes and 
contain data as well as transition descriptions that define possible be¬ 
haviour. Both, the behaviour and data associated to entities are sub¬ 
ject to change which allows for learning techniques. 

In the proposed approach, different points of views, hypothetical 
reasoning, or different granularities of simulation can be addressed 
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by using multiple worlds refering to (not necessarily) the same en¬ 
tities. For example, the beliefs of an agent which is modelled by an 
entity can be represented by a world that might differ from the data 
available in another world that represents an objective reality. This 
gives rise for epistemic reasoning capabilities, where e.g., an agent 
A thinks about what agent B thinks and acts upon these beliefs. 

The remainder of the paper is organised as follows. Next, we intro¬ 
duce the basic notions of a simulation-based programming paradigm. 
Section [3] discusses how to model different scenarios of AI applica¬ 
tions in the approach. We show how behaviour can be exchanged be¬ 
tween entities and discuss how evolutionary processes can emerge. 
Moreover, we demonstrate the use of different worlds for hypotheti¬ 
cal reasoning, expressing and exchanging different beliefs about facts 
and processes, and for using different granularities of simulation. In 
Section [4] we discuss interface considerations for transition descrip¬ 
tions. After that. Section [5] addresses the issue of maintaining con¬ 
sistency when data is updated by concurrent processes. Section [6] 
discusses the relation to existing techniques including differences to 
agent-based approaches and object-oriented programming. The pa¬ 
per is concluded in Section [7] with a short summary and an outlook 
on future work. 

2 Simulation-Based Programming 

In this section we explain the architecture of the proposed simulation- 
based programming paradigm on an abstract level. 

An SBP system deals with different worlds , each of which can 
be seen as a different point of view. The meaning of these worlds 
is not pre-defined by SBP, e.g., the programmer can decide to take 
an objectivistic setting and consider one world the designated real 
one or treat all worlds alike. Different worlds allow for example to 
model the beliefs of an agent as in an agent-based approach. Other 
applications are hypothetical reasoning or realising different granu¬ 
larities of abstraction for efficiency, e.g., parts of the simulation that 
are currently in focus can be manipulated by a world that offers a 
more precise simulation whereas parts out of focus are handled by 
another world that implements an approximation (see Section[3j. 

A world contains a set of named entities which are the primary ar¬ 
tifacts of SBP. Entities may have two sorts of named attributes: data 
entries which correspond to arbitrary data (including references to 
other entities) and transition descriptions which define the behaviour 
of the entities over time. The name of an entity has to be unique with 
respect to a world and serves as a means to reference the entity, how¬ 
ever the same entity may appear in different worlds with potentially 
different attributes and attribute values. Transition descriptions can 
be seen as the main source code elements in the approach and they 
are, similar to the data entries, subject to change during runtime. This 



allows for a dynamic setting in which the behaviour of entities can 
change over time, e.g., new behaviour can be learned, acquired from 
other entities, or shaped by evolutionary processes. We do not pro¬ 
pose a particular language or programming paradigm for specifying 
transition descriptions. It might, on the contrary, be beneficial to al¬ 
low for different languages for different transition descriptions even 
within the same simulation. For instance, a transition description im¬ 
plementing sorting can be realised by some efficient standard algo¬ 
rithm in an imperative language, while another transition description 
that deals with a combinatorial problem with many side constraints 
uses a declarative knowledge representation approach like answer- 
set programming (ASP) mm in which the problem can be eas¬ 
ily modelled. Declarative languages are also quite useful in settings 
where the transition description should be modified at runtime (as 
mentioned above) as they often allow for easy changes. That is, be¬ 
cause problem descriptions in these languages are typically concise 
and many declarative languages offer high elaboration tolerance |9], 
i.e., little changes of the problem statement require only few adapta¬ 
tions of the source code that solves the problem. 

We require transition descriptions—in whatever language they are 
written—to comply to a specific interface that allows us to execute 
them in asynchronous processes. In particular, the output of a tran¬ 
sition contains a set of updates to be performed on worlds, entities, 
data entries, and transition descriptions. When a transition has fin¬ 
ished, per entity, these changes are applied in an atomic transaction 
that should leave the entity in a consistent state (provided that the 
transition description is well designed). 

As mentioned, transition descriptions are executed in processes. 
Each process is associated with some entity and runs a transition de¬ 
scription of this entity in a loop. A process can however decide to ter¬ 
minate itself or other processes at any time, initiate other processes, 
and wait for their results before finishing their own iteration. 

We assume an infinite set J\[ of names and say that a concept c is 
named if it has an associated name n c £ A/”. We frequently use the 
data structure of a map , which is a set M of pairs (n, v) such that v is 
a named object, n = n v , and (n, ui), (n, V 2 ) £ M implies v\ = V 2 . 
With slight abuse of notation we write v £ M for ( nv,v) £ M. 
In the following we describe how the concepts discussed above are 
related more formally. To this end, we assume the availability of a set 
E of semantics for transition functions that will be explained later on. 

Definition 1 

• A transition description is a pair t = (sc, a), where sc is a piece 
of source code, and o £ E is a semantics. 

• A process is a tuple p = ( t , t;,), where t is a transition description 
and t{, is a timestamp marking the begin of the current transition. 

• An entity is a tuple e = {D, T, P), where D is a map of named 
data, T is a map of named transition descriptions, and P is a map 
of named processes. Entries of D,T, and P are called properties 
of e. 

• A world is a map of named entities. 

• An SBP configuration is a map of named worlds. 

We assume a pre-specified set T of updates which are descriptions 
of what changes should be made to an SBP configuration together 
with a fixed update function v that maps an SBP configuration, an 
entity name, the name of a world, and a set of updates, to a new SBP 
configuration. 

Definition 2 A result structure for a process p is a tuple r = (U , b c ), 
where U C T is a set of updates and b c is one of the boolean values 


true or false that decides whether process p should continue with 
another transition. 

A semantics a £ E is a function that maps a piece of source code, 
an SBP configuration, the name of a world, the name of an entity, 
and a timestamp to a result structure. 

Dynamic Behaviour For presentational reasons we forgo giving 
a precise definition of the runtime semantics of an SBP system that 
would require heavy notation but describe the behaviour of the sys¬ 
tem on a semi-formal level using the concepts introduced above. 

For running an SBP system we need an initial collection of worlds. 
Thus, let c° be an SBP configuration^ We assume a discrete notion 
of time where a run of the system starts at time 0, and that c* denotes 
the SBP configuration of each point in time t during a run. 

At every time t during the run of an SBP system the following 
conditions hold or changes are performed: 

• for each process p such that p = (f,tj,) £ P for some entity 
e = ( D , T, P) in some world w of c l there are three options: 

(i) p continues, i.e., p £ P' for entity e! = (D r ,T' , P') with 
n e > = n e in world w' £ c t+1 with n w i = n w \ 

(ii) p can be cancelled, i.e., p 0 P' for P' as in Item (i); 

(iii) p has finished its computation, i.e., the result of p, namely 

r v = a (sc, co, n™, n e , t) = ( U , b c ) 

is computed for t = (sc, a). The updates that were computed 
by p are added to a set Un e ,n w °f updates for entity e in world 
w, i.e., U C U* eyUw . 

The original process p is deleted similar as in Case (ii). How¬ 
ever, if b c = true then, at time point t +1 after t, a new iteration 
of the process starts, i.e., if there is an entity e' = {D 1 , T' , P') 
with n e / = ti e in world w' £ c t+1 with n w i = riw and there 
is a transition description t! £ T' such that = nt, then P' 

contains a new process p' = (f', t + 1) with n p / = rip. 

Why and when a process continues, is cancelled, or finishes is 
not further specified at this point because, intuitively, in an SBP 
system this depends on decisions within the process itself, other 
processes, and the available computational resources. 

• starting with c\ = c 3 4 , iteratively, for every item e in some world 
w of c l where the set (7. 4 , e of collected updates is non-empty, a 
new SBP configuration is computed by the update function: 

C'i+1 — tt(Ci, tie, Thw, U ne ^ Uw ) 

The SBP configuration c' n computed in the last iteration becomes 
the new configuration c t+1 of the system for the next point in time. 
We do not make assumptions about the order in which updates 
are applied for now and discuss the related topic of consistency 
handling in Section[5] 

Using names (for worlds, entities, and properties) allows us to 
speak about concepts that change over time. For example, if eo is 
an entity eo = (D, T, P) in some world at time 0 and some data is 
added to D for time 1 then, technically, this results in another entity 
ei = (D r , T, P). As our intention is to consider e\ an updated ver¬ 
sion of eo we use the same names for both, i.e., n eo = n ei ■ In the 
subsequent work we will sometimes refer to concepts by their names. 

3 In practice, c° could by convention consist of a single world with a process 

running a transition description for initialisation, similar to a main function. 



Along these lines, we introduce the following path-like notation us¬ 
ing the .-operator for referring to SBP concepts in a run. Assuming 
a sequence of SBP configurations c°, c 1 ,... in a run as above, we 
refer to 

• the world Wi € c 4 by ., 

• the entity e = { D , T, P) € Wi by n l Wi .n e , 

• the property * in D, T, or P by n' Wi .n e .n x (we assume that no en¬ 
tity has multiple data entries, transition descriptions, or processes 
of the same name). 

If clear from the context, we drop the name of the world or entity and 
apply the timestamp directly to entities or properties, or also drop the 
timestamp if not needed or clear. 

3 Modelling AI Applications in SBP 

The concepts introduced in the previous section provide an abstract 
computation framework for SBP. Next, we demonstrate how to use it 
for modelling AI scenarios. Note that in this section we will use high- 
level pseudo code for expressing the source code of transition de¬ 
scriptions and emphasise that in an implementation we suggest to use 
different high-level programming languages tailored to the specific 
needs of the task handled by the transition description. We discuss 
interface considerations for these embeddings of other formalisms in 
Section[4] 

Following the basic idea, i.e., simulating an intended scenario on 
the level of the programming language, entities in SBP are meant to 
reflect real world entities. In contrast to objects as in object-oriented 
programming (cf. Section[6]l, entities are not grouped in a hierarchy 
of classes. Classes are a valuable tool in settings that require clear 
structures and rigorously defined behaviour. However, in the scenar¬ 
ios we target, the nature of entities may change over time and the 
focus is on emerging rather than predictable behaviour. For example, 
in a real-world simulation, a town may become a city and a cater¬ 
pillar a butterfly, etc., or, in fictional settings (think of a computer 
game) a stone could turn into a creature or vice versa. We want to di¬ 
rectly support metamorphoses of this kind, letting entities transform 
completely over time regarding their data as well as their behaviour 
(represented by transition descriptions). Instead of using predefined 
classes, type membership is expressed by means of properties in SBP, 
e.g., each entity n e may have a data entry n e . types that contains a 
list of types that n e currently belongs to. 

Example 1 We deal with a scenario of a two-dimensional area, rep¬ 
resented by a single SBP world w, where each entity rtu,. n e may have 
a property n e - loc with values of form ( X , Y) determining the loca¬ 
tion of n e to be at coordinates {X , Y). The area is full of chickens 
running around, each of which is represented by an entity. In the be¬ 
ginning, every chicken ch has a transition description ch.mvRand 
that allows the chicken to move around with the pseudo code: 

wait(randomValue(1..5000)) 
dir = randomValue(1..4) 
switch{dir} 

case 1: return {'mv_up'} 

case 2: return {'mv_right'} 

case 3: return {'mv_down' } 

case 4: return {'mv_left' } 

The transition first waits for a random amount of time and chooses 
a random direction for the move, represented by the updates 


mv_up, mv-right, • • • C T. The semantics o/mvRand always re¬ 
turns ( U , true), where U contains the update (the direction to move) 
and true indicates that after the end of the transition there should 
be a new one. When the update function v is called with one of the 
mv updates it changes the value o/ch.loc, e.g., z/chlloc has value 
(3, 5} and the update is mvJeft then ch t+1 .loc has value (2, 5). 

Besides randomly walking chickens, the area is sparsely strewn 
with corn. Corn does not move but it is eaten by chicken. Hence, each 
chicken ch has another transition description eat with the code: 

if there is some entity en in myworld with 
en.loc = my.loc and 
en.types contains 'corn' 
then 

return {'eatCorn(en)'} 

Here, we assume that using the keyword my we can refer to proper¬ 
ties of the entity to which the transition description belongs ( ch in 
this case). Furthermore, myworld refers to the world in which this 
entity appears. Also here, every iteration of eat automatically starts 
another one. For an update eatCorn(en), the update function 

• deletes the location entry en.loc of the corn and 

• notifies the corn entity that it was eaten by setting the data entry 
en.eatenBy to ch (we will need the information which chicken 
ate the corn later) and adding a process to the corn entity with 
the transition description en.beenEaten that is specified by the 
following pseudo code: 

return {'delete_me' } 

that causes the corn to delete itself from the area. Unlike for the 
other transition descriptions, a process with en.beenEaten lasts 
for only a single iteration. 

Assume we have an initial SBP configuration c° = (w), where ev¬ 
ery chicken entity in w has an active process named move with tran¬ 
sition description mvRand and a process with transition description 
eat. Then, a run simulates chickens that run around randomly and 
eat corn on their way. 

While Example [I] illustrates how data is changed over time and 
new processes can be started by means of updates, the next example 
enriches the scenario with functionality for learning new behaviour. 

Example 2 We extend the scenario of Example\l\to a fairy tale the 
setting by assuming that among all the corn entities, there is one 
dedicated corn named cornOfWisdom that has the power to make 
chickens smarter if they eat it. 

This cornOfWisdom has a transition description 

cornOfWisdom.mvSmart; 

wait(randomValue(1..1000)) 
en is an entity in myworld where 
en.types contains 'corn' and 
there is no other entity en' 

in myworld where 
en'.types contains 'corn' and 
distance (en' .loc,my.loc) < 

distance(en.loc,my.loc) 
let my.loc=(myX,myY) 
let en . loc= (otherX,otherY) 
distX = otherX - myX 
distY = otherY - myY 



if IdistXI > |distY| then 
if distX > 0 then 
return {'mv_right'} 
else 

return {'mv_left'} 
else 

if distY > 0 then 
return {'mv_down'} 
else 

return {'mv_up'( 

Intuitively, this transition causes an entity to move towards the clos¬ 
est corn rather than walking randomly as in mvRand. Another dif¬ 
ference is that mvSmart processes have shorter iterations on aver¬ 
age as the range of the random amount of time to wait is smaller. 
The cornOfWisdom does not have active processes for this transi¬ 
tion definition itself but can pass it on to everyone who eats it. This 
is defined in the transition cornOfWisdom.beenEaten that differs 
from the beenEaten transition description of other corn: 

ch = my.eatenBy 
return {'delete_me' , 

'copyTransition(mvSmart,ch)' , 

'changeTransition(ch.move,mvSmart)'} 

Besides issueing the delete_me update as it is the case for 
normal corn, the update copyTransition(mvSmart, ch) 
copies the mvSmart transition description from the 
cornOfWisdom to the chicken by which it was eaten. The up¬ 
date changeTransition(ch.move, mvSmart) changes the move 
process of the chicken to use its new mvSmart transition descrip¬ 
tion instead of mvRand. Thus, if a chicken happens to eat the 
cornOfWisdom it will subsequently have a better than random 
strategy to catch some corn. 

Having means to replace individual behavioural patterns, as in the 
example allows for modelling evolutionary processes in an easy 
way. For example, if the chicken scenario is modified in a way that 
chicken which do not eat com regularly will die, a chicken that ate 
the cornOfWisdom has good chances to survive for a long period of 
time. Further processes could allow chickens to reproduce when they 
meet such that baby chicken may inherit which transition description 
to use for moving from one of the parents. Then, most likely, chicken 
using mvSmart will be predominant soon. 

The next example illustrates the use of worlds for hypothetical 
reasoning. 

Example 3 Entity barker represents a waiter of an international 
restaurant in a tourist area trying to talk people on the street into 
having dinner in his restaurant. To this end, barker guesses what 
food they could like and makes offers accordingly. We assume an SBP 
configuration in which for eveiy entity h that represents a human, 
there is a world wt that represents the view of the world of this hu¬ 
man. The following transition description barker.watchPeople al¬ 
lows barker to set the eating habits of passer-by in his world Wbarker 
using country stereotypes. 

wait(randomValue(50)) 

let en be an entity in myworld where 
en.loc near my.loc 
en.types contains 'human' 
en.eatingHabits = unknown 
country = guess most likely 


home country of en 

prototype = myworld.country.inhPrototype 
return {'setEatingHabits(en,propotype)', 

'setPotentialCustomer(en)'} 

For every country, Wbarker contains a reference inhPrototype to an 
entity representing a typical person from this country. The update 
setEatingHabits(pl, p2) copies transition descriptions and data 
properties that are related with food from person p2 to person pi. 
Moreover, the update setPotentialCustomer(p) lets barker con¬ 
sider entity p to be a potential customer. In order to choose what to 
offer a potential customer, the waiter thinks about what kind of food 
the person would choose (based on his stereotypes). This is modelled 
via the following transition barker. makeOffer: 

let cus be a potential customer in myworld 
w' = copy of myworld 
w'.cus.availableFood = 

restaurant.availableFood 
w'.cus.hungry = true 
intermediate return {addWorld(w'), 

startProcess(w'.cus.startDinner)} 
when process w'.cus.foodSelected is finished 
food = w'.cus.selectedFood 

return {praiseFood(food), deleteWorld(w')} 

To allow for hypothetical reasoning by the waiter, a temporary copy 
w 1 of the world Wbarker w created. The sole purpose of this world 
is to simulate the customer dining. We use a temporary world since 
the simulation uses the same transition descriptions that drive the 
overall simulation. For example, if we would use Wbarker instead, this 
would mean that barker thinks that the customer is actually having 
dinner. If we would use the world of the customer that would mean 
that the customer thinks she is having dinner and so on. 

After creating w 1 , the transition description defines that the food 
available to the version of the customer in w' is exactly the food 
that is on the menu of the restaurant and the customer is set to be 
hungry in the imagination of the waiter. Then, w' is added to the 
SBP configuration and a process for w' .cus is started using the tran¬ 
sition description startDinner that lets enitity cus start dining in 
w'. Note that the keyword intermediate return in the pseudo 
code is a convenience notation that allows for manipulating the SBP 
configuration during a transition which is strictly speaking not al¬ 
lowed in the formal framework of Section^ Nevertheless, the same 
behaviour could be accomplished in a conformant way by splitting 
barker.makeOffer into two separate transition descriptions that are 
used in an alternating scheme. As soon as the customer chooses some 
food in the simulation, transition barker.makeOffer is notified. It 
continues with reading which food has been chosen in the hypotheti¬ 
cal setting. Finally, the update praiseFood(food) causes the waiter 
to make an offer for the chosen food in the subsequent computation, 
whereas deleteWorld (w') deletes the temporary world. 

Note that copying worlds as done in Example [3] does not necessar¬ 
ily imply copying all of the resources in this world within an im¬ 
plementation of an SBP runtime engine (cf. the final discussion in 
Section|7]i. Moreover, it will sometimes be useful to adjust transition 
definitions in the copied world. For instance, when a transition defi¬ 
nition deliberately slows down the pace of the simulation as it is done 
in ExamplesQ]and[2]using the wait statement, it would make sense 
to reduce the waiting time in a world for hypothetical reasoning. An¬ 
other need for adapting a copied world is mentioned in Section [4] in 
the context of externally controlled processes. 


Example 4 We continue Examp le\3\ by assuming an SBP configura¬ 
tion where a tourist, Ada, passes by the waiter. His process for tran¬ 
sition barker. watchPeople classifies Ada by her looks to be an En¬ 
glishwoman. After that, the process for barker. makeOffer starts hy¬ 
pothetical reasoning about Ada having dinner. Following the stereo¬ 
types o/barker about English eating habits, the process reveals that 
Ada would go for blood pudding which he offers her subsequently. 
However, Ada is not interested in this dish as she is vegetarian. She 
explains her eating habits to the waiter, modelled by the following 
transition description ada.explainEatingHabits: 

let pers be current discussion partner 

in myworld 

if pers offers food containing meat then 
let w pers be the world of pers 
return {'setEatingHabits(w pers.me, 

myworid.me)'} 

Here, the update setEatingHabits that we used also in the previous 
example, the transition will overwrite the food related properties of 
the entity representing Ada in the world of barker with her actual 
eating habits, If barker runs the dining simulation again for making 
another offer the result will match the real choices of Ada. 

The last two examples showed how worlds can be used to express 
different modalities like individual points of views or hypothetical 
scenarios. Next, we sketch a setting where different worlds represent 
the same situation at different granularities. 

Example 5 Consider a computer game in which the player controls 
a character in an environment over which different villages are dis¬ 
tributed. Whenever the character is close to or in a village the in¬ 
habitants of the village should be simulated following their daily 
routines and interacting with the player. However, as the game en¬ 
vironment is huge, simulating all inhabitants of each village at all 
times is too costly. The problem can be addressed by an SBP config¬ 
uration that has two worlds, w(v) a ct and w(v) apx /or each village 
v. Intuitively, w(v) ac t simulates the village and its people in all de¬ 
tails but has only active processes while the player is closeby. The 
world w(v) apx approximates the behaviour of the whole village, e.g., 
increasing or shrinking of the population, economic output and in¬ 
put, or relations to neighbour villages, based on statistics and it has 
only active processes whenever the player is not around. Whenever 
the player enters a village, a process is started that synchronises the 
world w(v) ac t with the current state of the village in w(v) apx , e.g., 
by deleting or adding new inhabitants or shops. Moreover, it starts 
processes in w(v) ac t and cancels processes in w(v) apx . Another type 
of process is started when the player leaves again, that performs an 
opposite switch from w(v) apx to w(v) apx being active. 

While learning by simply copying transition descriptions from dif¬ 
ferent other entities as shown earlier already allows for many dif¬ 
ferent behaviour patterns to emerge, an SBP system can also be 
designed such that new transition descriptions are created at run¬ 
time. For example, by implementing mutation or crossing-over op¬ 
erators for decision descriptions, it is easy to realise genetic pro¬ 
gramming 0 principles in SBP. Another source for new transition 
descriptions is related to an important challenge in AI: learning be¬ 
haviour by watching the environment. In an SBP framework it is easy 
to incorporate existing learning techniques 1141 IT1 by means of tran¬ 
sition descriptions. Behaviour acquired by processes executing such 
transitions can then also be represented by means of transition de¬ 
scriptions and distributed to entities. 


4 Interface Considerations for Transition 
Descriptions 

As we want to allow for different formalisms to be used for transition 
descriptions it is important that they are able to interact smoothly. 
This is essentially already reached if their semantics respects the in¬ 
terface of Definition^ As different transitions communicate by read¬ 
ing and writing from and to the SBP configuration their formalisms 
do not need to be aligned in a different way. It is certainly necessary, 
however, that they use the same format for property values. 

The examples in the previous section already show some of the 
features that we think are useful in a language realising a transition 
description. For one, it is valuable to have generic keywords stand¬ 
ing for the name of the entity to which the transition belongs to and 
its world, like me and myworld in the examples. This way, if the 
transition description is copied to another entity or the same entity in 
another world it dynamically works with the other entity or world. 

We do not define an explicit user interface for SBP systems but 
suggest that interaction of the user or another external source with an 
SBP system by means of externally controlled processes: A transition 
description can use a dedicated ’external semantics’ where the result 
structure returned for every transition is provided by the user or an 
external system. Following this approach, an SBP system acts as a re¬ 
active approach that is influenced by events from its environment. By 
having the decision which parts are controlled externally and which 
ones within the system on the level of transition descriptions allows 
for having parts of the behaviour of an entity partially controlled by 
the user and partially by the system. Moreover, as decisions descrip¬ 
tions can be replaced at runtime it is also possible to take control 
over aspects previously handled by the system and, conversely, for¬ 
merly externally controlled transitions can be automatised. This way 
one can replace, e.g., a human player in a computer game by an AI 
player or vice versa. Naturally, this requires a proper modelling. For 
instance, in a simulation where worlds are copied for hypothetical 
reasoning like in the restaurant examples, a modeller would proba¬ 
bly want to replace human controlled processes by automated ones 
in the copied world. Otherwise, the user would have to provide addi¬ 
tional input for the hypothetical scenario. 

In the context of the model-view-controller pattern, an SBP config¬ 
uration represents the model and an SBP runtime engine corresponds 
to the controller. We suggest to handle the view outside of SBP, al¬ 
though it would be interesting to explore whether it is beneficial to 
also model graphical user interfaces inside SBP. 

5 Consistency of Data 

A key element of SBP is concurrent programming. Thus, a natu¬ 
ral question is how problems regarding concurrent access on data 
and consistency of data are handled in the approach. Conceptionally, 
conflicting updates that occur at the same time instant do not cause a 
technical problem as the update function v resolves an arbitrary set of 
updates to a valid follow-up SBP configuration. In practice, however, 
the functionality of this function has to be implemented and conflicts 
(e.g., deleting and changing a property of the same name at the same 
time) have to be addressed. Here, techniques for concurrency control 
in databases 0 could be useful. Moreover, it might be worthwhile 
to give the modeller means for specifying how to resolve individual 
conclicts by a dedicated language. Besides technically conflicting up¬ 
dates on data, another issue are semantical inconsistencies, i.e., data 
whose meaning with respect to the modelled problem domain is con¬ 
flicting. As an example, consider an SBP configuration modelling a 


banana and two monkeys and assume that each monkey has a tran¬ 
sition description that lets him grab the banana whenever it is laying 
on the ground. Now suppose that both monkeys detect the banana 
at slightly different times and their grabbing processes start. Then, 
after the first monkey has taken the banana, the process of the other 
monkey is still going on and, depending on the concrete modelling, 
it could happen that the system is in a state where each monkey is 
believed to have the banana. We argue that consistency problems of 
this kind should be tackled on the level of modelling rather than by 
the underlying computational framework as there are many types of 
issues that have to be addressed in different ways and also in the real 
world two monkeys could believe that they succeeded in getting a ba¬ 
nana for a short period of time. One solution in the example could be 
that the successful grabbing process of the first monkey cancels that 
of the other or that the grabbing update is implemented in a condi¬ 
tional way such that grabbing takes only place if the banana is still in 
place at the time instant when the process has finished. Although one 
cannot expect that problems of this kind are handled automatically, 
a concurrent formalism should allow for addressing them in an easy 
way. A major point for future work on SBP is to explore best prac¬ 
tices for avoiding inconsistencies in the first place by adequate mod¬ 
elling. Moreover, situations should be singled out in which incon¬ 
sistency avoidance requires much modelling effort but the respective 
problem could be handled by adding features to the framework. 

6 Influences and Relation to Existing Approaches 

A goal of our approach is to integrate the use of different AI tech¬ 
niques in a dynamic framework. Here, a main mechanism of integra¬ 
tion is using existing AI formalisms (e.g., ASP, planning techniques, 
etc.) for solving subproblems by means of transitions descriptions. 
This is similar in spirit to the use of different context formalisms in 
recent reactive forms of heterogenous multi-context systems SOD- 

The idea of using multiple worlds for different points of view and 
modalities is loosely related to the possible world semantics of modal 
logics (7). 

Evolutionary processes are intrinsic to many types of simulation. 
In, genetic algorithms CD the fitness of individuals is typically rated 
by a dedicated fitness function, whereas the most obvious approach 
in SBP is simulating natural selection by competition in the simu¬ 
lated environment, as discussed in the context of the chicken scenario 
after Example[2] The evolution of behaviour is related to genetic pro¬ 
gramming El where computer programs are shaped by evolutionary 
processes. Besides processes for the evolution of data and behaviour 
also other techniques that are frequently used in meta-heuristics, like 
swarm intelligence methods can be modelled and mixed in SBP in a 
natural way. 

Agent-based systems (ABS) |12 : , :GD share several aspects with 
SBP like the significance of emerging behaviour when entities are 
viewed as agents. This view, however, is not adequate for all types 
of entities in the SBP setting as an entity could also represent ob¬ 
jects like stones, collections of entities, or intangible concepts like 
’the right to vote’ which should not be seen as agents. Moreover, 
agents interact via explicit acts of communication that can but need 
not be modelled in an SBP configuration. Thus, we see SBP concep- 
tionally one level below ABS, i.e., SBP languages can be used for 
implementing ABSs rather than being ABSs themselves. 

Focuses of integration efforts in artificial general intelligence are 
communication APIs GD and design methodology ED- 

The shift of paradigm from procedural to object-oriented program¬ 
ming (OOP) can be seen as a step towards structuring programming 


to be more like the real world: in OOP, a world of objects of defined 
types. In particular, objects are instances of classes that are organised 
in a hierachy of classes in which data structures and behaviour can 
be inherited from top to bottom. While classes are well-suited for ap¬ 
plications that require a clear structuring of data, they also impose a 
rigid corset on their instances: the data and behaviour of objects is 
in essence limited to what is pre-defined in their class. Moreover, the 
type of object is defined on instantiation and does not change during 
runtime. In contrast, the behaviour and data of entities in SBP can be 
changed over time. Inheritance in SBP works on the individual level: 
entities can pass their transition descriptions and data entries to fel¬ 
low entities. Thus, compared to OOP, inheritance is not organised in 
a hierarchical way. The underlying motivation is to follow the main 
idea of simulating real world objects, taking the stance that entities 
in nature are individuals that are not structured into distinct classes 
per se. Instead of the instantiation of classes for generating new ob¬ 
jects, an important strategy for obtaining new entities in SBP is the 
prototype pattern: copying an entity that is closest to how the new 
entity should be like. As discussed in Section[3] other techniques for 
creating new objects are sexual reproduction or random mutation. 

Another difference between typical object-oriented languages and 
the SBP approach is related to the control flow. Like procedural pro¬ 
gramming, OOP programs are executed in an imperative way. Typi¬ 
cally, a run of a program in OOP starts with an entry method executed 
in a main thread from which child threads can be spawned in order to 
obtain concurrency. When a method calls another, it is per default ex¬ 
ecuted in the same thread, i.e., the execution of the calling method is 
paused until the called method has finished. In SBP, there is no main 
thread and each transition runs in an independent process. Thereby, 
the approach exploits the trend to concurrent computing due to which 
simulation became feasible for many applications. 


7 Conclusion 

In this work we proposed an approach for using simulation as a pro¬ 
gramming paradigm. The cornerstones of the approach are 

• typeless entities 

• different worlds for different views on reality 

• behaviour defined by heterogenous concurrent services 

• exchange of behavioural patterns and individual inheritance 

The main contribution of the paper is not a ready-to-use language 
but an initial idea for an architecture to combine these principles in 
a simulation-based programming paradigm. Clearly, there are many 
important aspects that need to be addressed when putting SBP in 
practice. Examples are the choice of data structures for entities, their 
interface when using different formalisms in transition definitions, 
and consistency of data as discussed in Section[5] 

As a next step we want to explore the capabilities of different for¬ 
malisms as a transition description language starting with ASP and 
identify different modelling patterns for important problems. A ma¬ 
jor goal is the development of a prototype SBP runtime engine which 
opens a wide field for further research: An important point is how 
to manage resources in SBP systems in which multiple worlds and 
entities share identical or slightly different data and processes. Ef¬ 
ficiency requirements could necessitate mechanisms for sharing re¬ 
sources, e.g., by only keeping track of differences when a world or 
entity is cloned. 
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